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"An Electronic Tranaao tion SvBfftm" 

Field of the Invention 

The present Invention relates to an electronic transaction system. The system Is 
particularly suited for tecilKa«ng the sale of sendees a«J/or goods In e,ecax.nic 
o format (such as software). 

Background Art 

The following discussion of the l>ackground of the invention is Intended to facilitate 
an understanding of «,e invention. However, it should be appreciated that the 
d,scussK>n is not an acknowledgement or admission that any of the material 
refened to was published, known or part of the common general knowledge of the 
per^n skilled In the art In any Jurtsdiotion as at the priority date of the appilcatton. 

Retailing of any good or service often requires the Input of multiple parties This 
input can be difficult to coK„dlnate, particularly in situations where the Input of one 
party, or even the need to contact that party for their input, is dependent on the 
15 input Of another party. In situations where the retailed sendee or good is 
drstnbuted over an eiectronfc networi.. this problem is further exacerbated by the 
common expectation that such services or goods can be provided immediately: 

Accordingly, ,s an object of the prosent Inventton to provWe an electronic 
transaction system that Is customisable in a manner that simplifies the task of co- 
20 oi^inating input from multiple parties over an electronic networtc 

A yet further problem with electronic transactton systems is the need for the 
electronic transacUon system to integrate with the existing, pervasive Electronic 
Funds Transfer at Point of Sale CEFTPOS") Infl^stmcture. This poses problems 
astheEFTPOSinfrastrticture: M ooiems 
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typlcally comprises transaction devices that include only an 
embedded payment applications because of their limited memory 
capacity; and 

• are highly regulated, such that any changes to an application that 
uses the EFTPOS Infrastructure must be recertified - a considerably 
costly process for the application owner. 

One prior method of overcoming this problem has been to integrate the 
transaction system with the embedded payment application. However, this 
solution requires the transaction acquirer or processor to modify their main switch 
to accommodate transaction transactions as well as payment transactions. Such 
modifications are expensive and time-consuming. 

It is therefore an optional, subsidiary, object of the present invention to provide an 
electronic transaction system that utilises the existing EI=TPOS infrastructure 
while overcoming, or at least partially alleviating, one or more of the 
aforementioned problems associated with the existing EFTPOS infrastructure. 

Disclosure of the Invention 

Throughout the specification, unless the context requires otherwise, the word 
"comprise" or variations such as "comprises" or "comprising", will be understood to 
Imply the Inclusion of a stated Integer or group of Integers but not the exclusion of 
any other Integer or group of integers. 

Further, the term "electronic service" is to be understood as meaning any service 
where the transaction constituting offer and acceptance of the service is 
conducted over an electronic medium. 

In accordance with a first aspect of the invention there is provided an electronic 
transaction system comprising: 



a host server; 
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at least one transaction device; 



at least one service provider system; and 
a content management system, 



Where the content management system provides content In the form of details of 
5 e,ec*.n,c goods and/or sendees able to be transacted by the electronic 
^nsacaon sy^em to the at leas, one transactton device and whe^. upon the at 
least one transaction device issuing a client request to the host server for one or 
more of the electronic goods and/or services detailed, the host se^r operates to 

10 ' '^'^ '° '^"^^ ^"^ 9«"e,at.ng the 

10 cent response, where necessary, issuing a service request to the at least one 
sen,,ce p^vider system and receiving a sen,ice response from the at least one 

service provider. 

Ideally, the electronic payment system further comprises a matrix recorting a set 

15 ann^ r "'"^ "^"^"'^ ^'^"'■= '-"-='ton system 

15 and Where the content management system references the matnx In determining 
he content to be pnovlded to each transaction device of the at least one 
tmnsaoton device to ensure that me set of pennissions and/or constraints are 



20 



a transaction device dimension; 
an electronic good or service dimension; and 
a merchant dimension, 

each dimension operable to recording infomiatlon In respect of the transaction 
25 8°°'^ °' ^""^ °' -e^hant, as appn,prtate, that may affect 

25 the content to be pmvided by the content management system 
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The host server may also determine whether the client request compiles with the 
set of permissions and/or constraints recorded in the matrix and references the 
matrix in generating a client response to ensure that the set of pemiissions and/or 
constraints are complied with. 

5 In a further preferred embodiment, each transaction device of the at least one 
transaction device receives a set of unique identifiers from the host server, each 
unique identifier representing a component of the content, the transaction device 
operable to checl< the set of unique identifiers against content alrBady provided 
and request content having unique identifiers not already provided from the 
10 content management system. The transaction device may further operate to 
discard components of the content having a unique Identifier not included In the 
set of unique Identifiers received from the host, server. Ideally, the unique 
identifier consists of a file name and at least one of the following: a version 
number; an error check value. 

15 Altematively. upon creation of content using the content management system, the 
content management system operates to provide the content to each transaction 
device of the at least one transaction device, in this manner, almost "real-time", 
download of content to transaction devices can be attained. 

The content preferably includes, in respect of each electronic service and/or good 
20 able to be transacted: at least one of the following: 

a description; 

a graphic to represent the electronic service or good; 
details of acceptable payment methods; 

details of acceptable validation or data entry mechanisms; and/or 



25 



details of any document to be provided when the sen^lce response 
confirms a service request was successful. 
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a menu structure for navigating the electronic services and goods able to 
be transacted; and 

details of any security meohanlsms implemented to control access to any 
restncted portions of the menu structure; 

each transaction device of the at least one transaction device may receive a 
scheduled time for transmission of content from the content management system 
each transaction device operable to ^quest the set of unique identifiers ftom the 
host server on the scheduled time. 

Preferably, the host sender operates to generate a client i^ponse in reply to the 
clrent request by reference to a process model, the process model conceptually 
oompnsing a series of steps and links, the armngement of one or more links In 
respect of a first step ropresenUng a second step to process on the fl,^ step 
rosolving to a predetermined result in a set of prodetemilned results. The set of 
predetemiined results, ideally, are a set of Boolean values and a fall result. 

The electronio transaction system may also Include at least one channel grouping 
each channel grouping associated with at least one transaction device where 
content provWed to each transacflon device of a channel grouping Is the same as 
content provided to each other trensactlon device In the same channel grouping 
At east one relattonship may also be included In the electronic trensactlon 
system each relationship recording details for facilitating communication between 
the host server and either a trensactlon device or a service provrder system, using 
therr respective native languages and communicatfon protocols. 

'r, a yet pretened embodiment, the electronic trensactlon system also includes an 
e^«ron,c inventoo,, the electronic lnven*,ry opereble to pro,.de an electronic 
good to the host sen,er on request. The request from the host server for an 
electronrc good may Include a goods identifler. the electronic Inventory opereble 
to pro«de an electronic good having a conesponding goods identmer in response 
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to the request. To combat potential fraud, on return of an electronic good to the 
electronic Inventory, the electronic good is not able to be provided in response to 
a request from the host server for a predetenmined period of time. The electronic 
good may be a serial number to be provided in redeeming an electronic service 
5 able to be transacted. 

The electronic transaction system may be operable to issue both synchronous 
and asynchronous service and client requests. Asynchronous service requests 
and asynchronous client requests include a con-elation key and any response to 
the asynchronous service request or asynchronous client request, as appropriate. 
10 includes the con-elation key. As asynchronous service requests can cause 
confusion for the host server, the host server may be operable to distinguish 
between a service response and a client request by reference to the con-elatlon 
key and/or type. 

Preferably, each service request, service response, client request and client 
15 response is communicated via at least one message bus. The message bus may 
use a publish/subscribe mechanism of communication. 

Ideally, the transaction device includes at least one payment application. Using 
an intennediate router having a dedicated connection to the host server and to a 
payments host, the transaction device may forward a service request issued by a 
20 transaction device to the host server and fon^/ard a payment request Issued by the 
payment application of the transaction device to the payments host. 

In a potential alternate processing method, the transaction device issues an 
authorisation request to the intemiedlate router for fonwarding to the payments 
host and receives an authorisation reply from the payments host via the 
25 intennediate router and where, if so authorised, the transaction device thereafter 
Issues a service request to the host server via the intennediate router and, upon 
receiving a service response indicating that the sen^ice request was successful. 
Issuing a payment request to the payments host via the Intennediate router. 
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The transaction device may further include removable, writeable media for 
recording one or more of the following: a receipt; an electronic good; details of the 
client request; details of the client response. 

The host server may operate to confimi the identity and/or capacity of the 
5 transaction device that issued the client request and. if the Identity of the 
transaction device can not be confirmed, or the capacity of the transaction device 
is exceeded, ignore the client request. 

In accordance with a second aspect of the present invention there is a host sen/er 
for use in an electronic transaction system according to the first aspect of the 
10 Invention. 

In accordance with a third aspect of the present Invention there is a transaction 
device for use in an electronic transaction system according to the firet aspect of 
the invention. 

In accordance with a fourth aspect of the present invention there is a method of 
15 performing an electronic transaction comprising the steps of: 

providing content in the form of details of electronic goods and/or services 
able to be transacted to at least one transaction device; 

receiving a client request for one or more of the electronic goods and/or 
sen^ices detailed from a transaction device; 



20 



generating a client response In reply to the client request which, where 
necessary, includes issuing a service request to at least one service 
provider system and receiving a service response from the at least one 
service provider. 



25 



Ideally, the method also Includes the step of referencing a matrix recording a set 
of pemiissions and/or constraints to ensure that the content to be provided to 
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each transaction device complies witli tlie recorcled set of permissions and/or 
constraints. 



Preferably, the metliod aiso includes tlie steps of determining whetlier the client 
request complies with the set of permissions and/or constraints recorded in the 
5 matrix and the step of generating a client response includes the sub-step of 
referencing the matrix to ensure that the set of penrjissions and/or constraints are 
complied with. 

The method may also include the step of sending a set of unique identifiers to 
each transaction device, each unique identifier representing a component of the 
0 content, and the step of transmitting any content having unique identifiers not 
already provided to the transaction device upon request by the transaction device. 
Additionally, the method includes the step of receiving a request for the set of 
unique identifiers from each transaction device at each transaction device's 
scheduled time. 



Preferably, the step of generating a client response includes the substep of 
executing a process model, the process model conceptually comprising a series 
of steps and links, the arrangement of one or more linl<s in respect of a first step 
representing a second step to process on the first step resolving to a 
predetermined result in a set of predetemnined results. 

The method also includes the step of associating each transaction device with at 
leat one channel grouping, the content provided to each transaction device of a 
channel grouping being the same as content provided to every other transaction 
device in the same channel grouping. 

Ideally, the method includes the step of recording details for facilitating 
communication between the host server and each transaction device and the host 
server and each service provider system to form a set of relationships and the 
step of using the appropriate relationship in the set of relationships to facilitate 
communication between the host server and transaction device or service 
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provider system, as appropriate, In their respective native languages and 
communication protocols. 

The method may also Include the steps of issuing a request to an electronic 
Inventory for an electronic good and receiving an electronic good from the 
5 electronic inventory. 

Preferably, the method also includes the step of distinguishing between a service 
response and a client request by reference to a correlation key in the service 
response and/or type. 

The method may also include the step of communicating service requests, service 
10 responses, client requests and client responses by way of at least one message 
bus using a publish/subscribe mechanism of communication. 

Preferably, the method includes the steps of confirming the Identity and/or 
capacity of the transaction device that Issued the client request and the step of 
ignoring the client request if the identity of the transaction device can not be 
1 5 confinned or the capacity of the transaction device Is exceeded. 

Brief Description of the Drawings 

The Invention will now be described with reference to the following drawings, of 
which: 

Figure 1 Is a schematic representation of an electronic transaction system. 

20 Figure 2 is a conceptual representation of a process model step, with link 
attachments, as used in the electronic transaction system of Figure 1. 

Figure 3 is an illustration of process flows of a host server as illustrated in Figure 
1. 

Figure 4 is a diagram of a transaction sequence used by a transaction device 
26 when communication with the host sery^er as illustrated in Figure 1 . 
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Figure 5 is a schematic of the components of a multi-purpose transaction device 
for use in the electronic Transaction system of Figure 1 . 

Best Mode(s) for Carrying Out the Invention 

In accordance with the present Invention there is an electronic transaction system 
5 10. in the electronic transaction system 10 being described, and as shown In 
Figure 1. the electronic transaction system 10 comprises: 



10 



15 



a host server 12; 



at least one transaction device 14; 

at least one service provider system 16; 



databases 18; 



process designer 20; 



content management system 22; 



scheduler 24; 



channels matrix 26; 



schedule management module 28; 
merchant reporting module 30; 



management module 32; 



accounting and settlement module 34; 



business procedure definition module 36; and 



5 



10 



15 



20 
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Channels matrix management module 38. 
Host Servftr io 

The host server 12 operates ,o provide ^ssage broKering seMoes befcveen 
Wants .nvolved in an exchange of messages. As such, the host server 12 i 
in data oommunlcation with the at least one tmnsaction device 14 sendee 
provider systems 16, databases ift ^ ■ 

' ' "^"^^ 18, process designer 20 and content 

management system 22. The host sen,er 12 further comprises: 

• adaptors 40; 

• process automation engine ("PAE") 42; 

• electronic Inventory 44; and 

• monitoring system 46. 
Adaptors 40 

Adapto^ 40 can be ctessMed as fronts™, adaptor 40a and baCend adaptors 

Zsaca r ^ "^'"^ "'^ communication With 

t.3nsactK,n devices 14. Backend adaptors 40b ..sponsible for data 

oommun^ation w«h sen.ce p„.,.der systems 16. In other respects. f^JZ 
adaptors 40a and back-end adaptor 40b are basically Monacal. 

Each adaptor 40 has an associated relationship. In the context o, the functtons of 
an adaptor 40. a .la«onship .p^sents data necessa^ for transfomiing 
messages receded by the adaptor 40 f.m a fonnat native to the adaptor's 40 
assoca ed t.nsac«on device 14 or sendee p.vider system 16, into I ZZ 
nat.e to the PAE 42 and vice ve.a. Thus, by reason o, „s asso^ed 
relatonship. the adaptor 40 is opei^bie to act as a translator 



wo 2005/001725 



PCT/AU2004/00085S 



-12- 

Adaptors 40 "listen" for transaction messages from its respective transaction 
device 14 or service provider system 16. as appropriate. On receipt of a 
transaction message, the adaptor 40 operates to transfomi the message in 
accordance with Its associated relationship for fon^/arding to the PAE 42. 
5 Similarly, on receipt of a message from the PAE 42. the adaptor 40 operates to 
transfomn the message In accordance with its associated relationship for 
foHA/arding to its respective transaction device 14 or service provider system 16. 
as appropriate. 

PAE 42 

1 0 The PAE 42 Is not a single component, but a logical concept comprising: 



15 



at least one process model 48; 



message buses 62; 



a message receiver 64; 



at least one request handler 66; 



a retry receiver 68; and 



at least one process executor 70. 



Process Model 4ft 



Process model 48 Is. as described In more detail below, a programmatic 
representation of a business procedure. However, a process model 48 is able to 
represent any short-duration process that needs to happen repeatedly in a 
predictable manner. 
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Message Buses 69 



5 



Message buses 62 are used for communicating messages intemaily between 
electronic transaction system 10 components. Message buses 62 work on a 
publish/subscribe an^ngement. Messages are published by various components 
to the desired message bus 62. Such messages may Include extra infomnatlon. 

The various components subscribe to the desired message bus 62 in order to 
receive messages. Subscription requires the component to specify subscription 
critena. Thus, on a message being published to the message bus 62 the 
message bus checks the message against the various subscription criteria of Its 
10 subscribers. Where the message matches the subscription criteria of a 
subscnber. the subscriber Is notified of the publication of the message to the 
message bus 62. 

In the embodiment being described there are four message buses 62 - inbound 
message bus 62a: outbound message bus 62b: retry message bus 62c: and 
15 response message bus 62d. 

Message Receiver 64 

Message receiver 64 subscribes to inbound message bus 62a. When notified of 
the existence of a message, the message receiver 64 operates to decode the 
message. This is done with reference to the relationship associated with the 
20 adaptor 40 through which the message has been received. In this manner while 
.n the context of translation by an adaptor 40. the relationship is agnostic as to the 
. content of the message, in the context of processing of the message for the 
purposes of the message receiver 64. the relationship may also be Interested In 
the content of the message. 

25 Once decoded, the message receiver 64 operates to detemilne whether the 
message is a client request or a service response. In this regard. If the message 
includes con:elatlon infomiation. the message received 64 designates the 
message a service response and operates accordingly (refer to the examples 
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below). ,f me message does not Include correlation information, the message 
mce«/er 64 assumes that the message is a client request, ie any request for an 
electronpc good or service from a transaction device 14. (Note thai in some 
.nstances the message receiver 64 may be able to detemilne that a message Is a 
5 sen„ce response by nature of the format of the message, even in the absence of 
conelaton infomnation). Client requests a,e then ,bn«a«,ed to request handler 

Request HanHlor ft« 

Each relationship has an associated request handler 66. On receipt of a client 
10 ^uest, the .quest handler 66 e«her p^ses the Clent request J t 
dentif^es the app„,priate process model that the process executor 70 executes 
In the latter an^ngement. the request handler 66 fo^ards the client request to the 
process executor 70. 

Retry Refiftivar Ra 

15 R-^-Bcelver 68 IS a subscriber to thereby message bus 620. The functions of 
the retry receiver are described In more detail In the examples below. 

Process Eyftrii»r>r 7n 

.request handler 66. To some extent, however, the process model 48 is self! 
20 execuar^. The Cent request pro^des the initial data upon which the p^oess 
model 48 operates. 

Electronic Inventory 44 

TT>e electmnlc Inventory 44 Is used to store activated elect«>nlc goods. TT,e 
electronic goods may, amongst others, take the fomi of movie pass numbers 
25 recharge codes for telecommunications carriers or software 
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Electronic goods in the electronic inventory 44 are serialised and are often 
represented by a 'PIN'. The PIN is a unique number the service provider uses to 
identify a purchased electronic good. Typically, the PIN is encrypted and is kept 
private until the time of issue. 

5 PINs cannot be issued twice. An electronic good in the electronic Inventory 44 
can be used only once. To this end, the electronic inventory 44 must guarantee 
that a PIN is issued at most once (subject to the following exception). 

Electronic goods are typically supplied as a data file containing serialised 'PINs'. 
The serial numbers are a tracking mechanism for PINs, the PINs are effectively 
10 the delivered good. The need to allocate a serial number to each stock item is 
necessary, for supplier relationship purposes. The serial numbers are a public 
identifier of the electronic good and can be used for reconciliation and problem 
solving. 

If an electronic good Is returned, it Is put In escrow for a predetennlned period of 
15 time and may be reconciled with the supplier to detemiine if it was used or not. 
Upon completion of the electronic good's escrow period, the unique electronic 
good is able to be resold. 

The need to keep the electronic goods in escrow for a predetermined period of 
time is for fi^aud prevention purposes. When a return of a successfully delivered 

20 electronic good occurs, the merchant is still in possession of the electronic good 
and may try to use the electronic good in some way. If the electronic good was 
then issued to a customer of another merchant, who then proceeded to redeem 
the electronic good after the initial merchant has used the electrxDnic good, the 
redemption would be blocked because of the fraud of the initial merchant 

25 However, by placing the electronic good Into escrow for a period of time, the 
chance of this type of fi^ud occurring is reduced and/or perpetrators of this type of 
fraud can easily be identified. 



Electronic Inventory 44 receives service requests from the PAE 42. 
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Monitoring System 46 

Monitoring system 46 operates on a proactive and reactive level. When operating 
on a proactive level, monitoring systeni 46 checks key aspects of the operation of 
the host server 12. if this check reveals that one or more alert conditions are 
5 satisfied, an alert is generated. The alert is sent to an appropriate representative 
of the operator of the electronic transaction system 10 by way of e-mail or SMS 
message. 

When operating on a reactive level, the host server 12 may itself issue a problem 
notification to the monitoring system 26. The monitoring system 26 then 
10 generates an alert. Again, the alert is sent to an appropriate representative of the 
operator of the electronic transaction system 10 by way of e-mail or SMS 
message. 

Transaction Device 14 

Each transaction device 14 comprises a processor and memory means. The 
15 processor Is operable to execute embedded software stored on the memory 
means. The embedded software comprises a transaction application and a 
payment application. 

The transaction application is similar to a web browser in nature. It downloads 
content from the content management system 22 on a periodic basis. This 
20 downloaded content may Include data relating to: 

• a description of the service and/or good to be provided; 

• the graphics to be displayed in respect of the service and/or good; 

details of acceptable payment methods for each service and/or good; 

details of acceptable validation or data entry mechanisms for each 
25 service and/or good; 
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. details of any document(s) to be provided to the customer on 
successful sale of an electronic sen/ice or good. 

menu stmcture for navigating the various services and/or goods 
available for purchase; and/or 

5 . details of any security mechanisms implemented to control access to 

any restricted portions of the menu structure. 

As such, the downloaded content is used by the transaction application to 
generate a user interface through which a customer interacts to purchase an 
electronic service or good. The concept of the user interface Is important, as It 
10 provides functionality akin to a nonnal EFTPOS transaction. 

The use of downloaded content as the means of developing the user interface 
means that the transaction application does not change when a new electronic 
service or good is to be added to the electronic transaction system 10 As a 
result, there is also no need for the transaction application to be recertified. 

15 As discussed above, the downloaded content may Include authentication data 
entry and document detail Infomiatlon. As a result, the transaction application 
must also be capable of controlling a printer, card reader or other peripheral 
device connected to. or Integrated into, the transaction device 14. 

The payment application Is typically an EFTPOS payment application. However 
any payment application capable of processing payment from a customer may be 
used. The payment application is separate from the transaction application The 
payment application and transaction application can communicate though by 
means of an application programming interface. In this manner, the transaction 
application does not interfere with the functionality of the payment application. 

26 This Is also important as it means that security concerns regarding payment 
processing ar^ separated from security concerns regarding transaction 
processing. 



20 
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Each transaction device 14 is associated with a merchant. 
Servic e Provider Systems Ifi 

Service provider systems 16 represent the computer systems associated with the 
various suppliers of the electronic services and goods. Each seivice provider 
system 16 is in data communication with the host server 12. The processing 
performed by each service provider system 1 6 is beyond the scope of tlie present 
invention and therefore the service provider systems 16 will not be described in 
further detail. 

Databases 18 



10 



Databases 18 comprise an administration database 18a. a transaction database 
18b and a reporting database 18c. Administration database 18a stores 
information relating to the at least one transaction device 14 and the merchant 
associated with each transaction device 14. Transaction database 18b holds 
infomnation on each transaction processed by the electronic transaction system 
15 10. Reporting database 18c holds the same Infomiation as held in administration 
database 18a and transaction database 18b. but in a simplified form, particularly 
optimised for reporting. In this manner, the transaction database 18b is also 
relieved of some processing load. 

As Infomiation is constantly being written to the databases 18. and the timing and 
20 type of Infomiation to be written to the databases 18 would be known to the 
person skilled in the art. specific instances will not be described herein. 

Process Designer 20 

Process designer 20 is used to create the process model 48. While the process 
model 48 is computer software, conceptually, a process model 48 consists of a 
25 series of steps 60 and links 52. 



10 
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As shown in Figure 2. the position of each Wnk 52 provides direction as to the next 
step 50 to execute based on the outcome of the present step 50. To elaborate 
links 52 that connect to the top of the step 50 represent the connection from a 
parent step 50 (ie. the step 50 that has just finished processing). Links 52 that 
sprout from the left of step 50 represent the connection to a child step 50 that Is to 
execute on failure of the current step 50. Links 52 that sprout from the bottom of 
step 50 represent the connection to a child step 50 that is to execute on the 
cun-ent step 50 resolving to a value of "FALSE". Links 52 that sprout from the 
nght of step 50 represent the connectfon to a child step 50 that Is to execute on 
the current step 50 resolving to a value of TRUE". Thus, each step 50 must 
resolve to a Boolean value or fail. 

IVIultiple links 52 may sprout from the Jeft. right or bottom of a step 50 as a means 
of indicating parallel child steps 50 to be processed on resolution of step 50. 

This unifomi structure for process models simplifies processing for delivery of the 
electronic good or service. 



Content Managem ent System 79 

In essence the content management system 22 controls the construction, release 
and maintenance of content downloaded by transaction devices 14. However in 
doing so. the content management system 22 references the channels matrix 26 
to ensure that any constraints recorded In the channels matrix 26 are not 
contravened. In doing so. this may result in exclusion of pari, or all. of the 
content. 

The content management system 22 comprises a user navigation designer 54 a 
document designer 56, a channel groupings module 58 and a content download 

management module 60. 

The user navigation designer 54 allows for cnsatlon of a menu system ultimately 
neplrcated on the transaction device 14 following content download. It also allows 
a party to designate In what manner the customer is i^quii^d to interact with the 
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transaction device 14 in order to purchase the specified goods and/or services 
For example, using the user navigation designer 54 anyone may specify what 
.nfomiation. if any. is to be obtained by means of magnetic swipe card or an 
external keyboard, for example, infomiatlon in respect of the customer's acdount 
5 number. 

The document designer 56 facilitates the graphical design of documents to be 
pnnted by the transaction device 14. The designed documents fom, part of the 
content. Ideally, document designer 56 is used to produce receipts to be Issued 
to customers upon completion of a successful transaction. 

10 Channel grouping module 58 facilitates allocation of a transaction device 14 to a 
Channel grouping. A channel grouping represents a collection of transaction 
devices 14 that are to receive the same content. 

Each transaction device 14 can belong to one or more channel groupings A 
transaction device 14 can have its channel grouping changed or have a channel 
1 5 grouping added at any time. 

Content download management module 60 facilitates the scheduling of 
downloads for particular transaction devices 14 or channel groupings. In this 
context, the content download management module 60 notifies each transaction 
device 14 of its scheduled time to download content. The transaction device 60 
20 then contacts the host sender 12 at the scheduled time to initiate the content 
download. 

The content download management module 60 also manages the reporting of the 
success or failure of a scheduled download, as appropriate. 



25 Scheduler 24 and schedule management module 28 combined operate to 
manage any scheduled task, other than content download. One scheduled task 
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handled by the scheduler 24 and schedule management module 28 is the periodic 
transmission of a transaction listing to service provider systems 16. 




The channels matrix 26 is central to controlling whether a merchant can sell a 
5 product, and if so. for what price, and at what commission. The channels matrix 
26 is also used during transaction processing to ensure that the rules 
implemented therein are always satisfied. To elaborate, if the content of a 
transaction device 14 is somehow out-of-date, the channels matrix 26 may 
disallow a sale of a product if it is being sold for an incon-ect price. 

10 Channels matrix management module 38 manages the channels matrix 26. 
Channels matrix 26 is a multi-dimensional matrix used to control the electronic 
services and/or goods available for sale by each transaction device 14, channel 
grouping or merchant. Factors covered by the channels matrix 26 Include: 

• availability; 
15 • pricing; and 

• merchant margin (ie. commission). 

In this manner, the availability and price of an electronic sen^ice or good may be 
adjusted based on such factors as the locality 6f. or industry segment of the 
merchant associated with, the transaction device 14. The channels matrix 26 
20 further allows for business rules, such as "merchants in industry X, belonging to 
bank Y. cannot sell electronic service Z after date D", to be implemented - each 
business rule having a predetennined lifespan. 

The dimensions of the channels matrix 26 are composed of attributes of the 
device, the merchant and the electronic good or service. An example of a device 
25 attribute is 'Location'; an example of a merchant attribute is 'Retailer Group'; and 
an example of an electronic good or service is 'Brand'. Implemented business 
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rules are made by combining attributes of merchants and devices and electronic 
goods or services. 

Business ™ies are cumulaflve. If more than a single rule applies to a device for 
merohant maigln or price than an algorithm is used ,o establish the mos, •relevant' 
6 mle. Th,s algorithm is basSd on a weighting value scheme between attributes. 

Merchant Rep orting Mnrinia 

The merchant reporting module 30 allows merchants and other operators of 
transaction devices 14 to access a series of secure reporting sevens. Each 

10 r H Tr,"'*' - -o-^e-' within reporting database 

10 18c or details of transactions presently being processed by the PAE 42 The 

transaction details may be pn^vided as drill down graphs or summaries «s deslrad 

by the merchant or operator, as appropriate. 

Mananam ant Modiila a y 

Management module 32 allows for a transaction device 14 or senrioe provider 
15 system 16 1o be declared Inacflve. When a transaction device 14 Is decla^d 
.nactive the host server 12 Is not able to racelve *ansactlons from the transaction 
device 14. When a service provider system 16 Is declared inactive, the host 
se^er 12 ,s not able to process any transactions requesting purchase of an 
electronic service or good provided by the merohant associated witt, the sen,ice 
20 provider system 16. 

The management module 32 also manages Information In r«spect of each 
transaction device 14, merohant supplier, channel, Industiy segment and other 
global infbmiation made use of by the electronic transaction system 10. 

Accounting anH g ettlamant Mf rtyl^ ■»/. 

25 Ac^unting and settlement module 34 perlbmis procedures that provide for 
settlement between a merchant and the operator of the electronic transaction 
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system 10. This rs raquined because the operator of the electronic transaction 
system 10 Is not an acquirer of the financial transaction (transactions processed 
by the transaction device 14 accraing to the merchant who made the sale). 

.Business Procedure n»B nitlon Kr^ .,^^ ■»= • 

5 The business pnoceduro definition module 36 fecllltates the definition of 
nepeatable business processes, such as Yelease a new product' or 'change the 
merohan, margin for channel X'. Often there am many repeatable business 
processes surrounding the brokering of electronic goods or services A 
repeatable business proceduro helps to maintain quality and consistency within 
1 0 the electronic transaction system 1 0. 

Business procedures are stored In the administretion database 18a. 

The invention will now be described In the context of two examples of Its expected 
use. With additional components being described as necessary. As the two 

Using process designer 20, an administrator of the electronic transaction system 
10 creates at least one process model 48. Each process model 48 Is 
representative of the processing subsequently to occur by the PAE 42 on receipt 
Of an appropriate client request. 

20 The administrator also Checks the level Of stock in the electronic inventory 44 ,f 
Tuppfer' " ^ """^ *° *^ ^0'"°'"^*^ 

The supplier then provides the stock in the ibm, of an encrypted file of 
prede^emnined fom.at. Ideally, the stock recorded in the encrypted file Is delivered 
rn an rnactive" state. ,n this manner, the stock cannot be used by another party 
Who may receive the encrypted file by mistake. Upon successft., decryption of the 
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file, the administrator confine receipt of the file with the supplier. In tun, the 
suppl,er operates to acflvate fl^ stooK recorded In the encry^tl^. 

^'"'"'^'"'"^ " ^ S-^-e^ content 

™iat.ng to «,e proposed delivery of an eleC^nlc good or sen,lce using the contem 
5 management system 22 The content m=,„ = using me content 

mn,^ . K ihe content management system 22 only allows 

content to be generated .ha. confom,s wi.h the consU^ints reco J in Z 
Channels matrix 26. The administrator or memhant may also act to a^dl or 
amend aiiocations of, transaction devices 14 to channel g„,up,ngs a 
necessa-yfor appropriate delK,eryoftheeleC„n.o good or se-vlL. 

content the content download management module 60 communicates v«.h the 
fansac^ on dev,ce 14 via the in,em,ediate »uter. The communication intones the 
t^nsacuon device of .he scheduled «me that it shou« contaC hos. se JTl J o 

15 aHn r"*'"* ~ generated y «l 

1S administrator or merchant, as appropriate. 

irrrrT ^ ^^^^ ^ ~ hos. 

^™er 12, tt,r»ugh an rntemrediate router (discussed In mo,^ detail below) ,„ 
.^ponse, host server 12 sends to the payment device 14 - again I «L 
intermed ate router - a eot «f "aam. via tne 

20 chec. (CRC, number.. ^""^ ^^=°'='^'^ -'"™^-<=V 

d^,"?H? """^^"'^ ^ °'*e content to be 

downloaded ,o memo^. However, as the .«nsac«on device 14 Is l^w 
and^dth device, a comparison is fir. made between each filename J 

25 nul °' ^"^ """'"^■^ '^^ ™- — and CRC 

nsrc^sT"'^™*'""''"""^°'~^''-''^<'°-'-<'ed. only in 
rnstances where a file name and CRC number In the set of file name and CRC 
numbers does not match a file name and CRC number associa, v^^ 
components of content already downloaded does the transac«on vrL h 

30 ^^""^ *° °' content having he Jn 

matchrng file name and CRC numbers f.m content management sy^eml 
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Those components of content already downloaded that have an associated file 
name and CRC number that does not match a file name and CRC number in the 
set of file names and CRC numbers are deleted from memory. In this manner 
the file name and CRC numbers of components of the content stored in memory 
5 always exactly match the file names and CRC numbers In the set of file names 
and CRC numbers received from host server 12. 

The content stored in memory is then used by the transaction application to 
generate a user interface through which a customer interacts to pun^ase an 

electronic service or good. 

0 Once a customei^s selection of a transaction has been completed using the user 
interface, the transaction device 14 operates a modem that fomis part of the 
transaction device 14. The modem, via a telecommunications network to which it 
IS connected, forms a connection with the intermediate router. 

Intemiediate router has dedicated connections to both a payments host and host 
5 server 12. In this manner, both service- and payment-related transactions can 
occur within the scope of a single call. The intermediate router firstly attends to 
the payment-related transaction by fonA^ardlng the transaction to the payments 
host. On successfully transacting payment, the payments host sends an 
authorisation response back to the intemiediate router. The intemiediate rx>uter 
) fonvards the authorisation response to the transaction device 14. 

The intermediate router then fon«/ards the service related transaction to host 
server 12 who treats the transaction as a client request. Host server 12 receives 
the client request at adaptor 40a. 

The adaptor 40a then publishes the request to Inbound message bus 62a along 
with message context information. The message context Infomiation indicates any 
errors that occurred during delivery as well as any other infomiation the adaptor 
40a may include. The message context Infomiation will often Include an identifier 
the adaptor 40a can use as a correlation key. This is the first correlation key 
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The adaptor 40a then awaits a response fronn the PAE 42 regarding the request. 
To receive such a response, adaptor 40a subscribes to outbound message bus 
62b for messages published by the PAE 42 including the first con-elation key. 

Message receiver 64 also has a subscription to inbound message bus 62a. Its 
subscription is for all new client requests. Thus, on publication of the request 
inbound message bus 62a notifies message receiver 64 of the existence of the 
request. The message receiver 64 then retrieves the request from the inbound 
message bus 62a. 

As the message retrieved from, the inbound message bus 62a Is unknown to the 
message receiver 64. message receiver 64 initially treats the message as a client 
request. However. , the message receiver 64 thereafter decodes the message 
using the relationship associated with adaptor 40a. Once decoded, and as 
mentioned above, the message receiver 64 operates to detennine the type of 
message by reference to: 

^ 'the inclusion or omission of a conrelation key; and/or 

• the format of the message. 

In this example, as message receiver 64 resolves the message to be a client 
request, the message is passed to request handler 66. 

Request handler 66 processes the message to determine the appropriate process 
20 model 48 to use to execute the client request. Once the appropriate process 
model 48 has been detemiined. control is passed to process executor 70 to 
execute the process model 48. Typically, for electronic services a 'sen/ice master 
process model' will be used. Within this services master process model, specific 
processing will be performed for a particular electronic service by identifying the 
25 requested 'service ID' in the client request message. Each service ID will have a 
process model 48 associated with it and the service master process model will 
execute this sen/ice specific process model 48 as a sub-process. 
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It is at tfiis point tlnat tlie examples differ. 

In this, the first example, process model 48 includes an asynchronous service 
request and then a synchronous service request. Processing executes as normal 
until the asynchronous service request is reached. 

5 In executing the process model 48. process executor 70 subscribes to response 
message bus 62d In order to properly process the asynchronous service request 
The subscription is based on a second correlation key. 

As the asynchronous service request is to be issued to service provider system 
16. It is necessary for the process executor 70 to encode the asynchronous 
10 service request. Encoding is made in accoixlance with the relationship associated 
with adaptor 40b. itself associated with service provider system 16. The encoded 
asynchronous service request is then published to outbound message bus 62b 
The encoded asynchronous service request includes the second con-elation key. 

Processing of the process model 48. then proceeds as per normal. 

15 Adaptor 40b is also a subscriber to outbound message bus 62b. Adaptor 40b 
subscribes on the basis of the services that it offers (which necessarily need to be 
incorporated into encoded asynchronous service request message). Accordingly 
on publication of the encoded asynchronous service request message, outbound 
message bus 62b notifies adaptor 40b of the publication of the encoded 

20 asynchronous request message. Adaptor 40b then retrieves the encoded 
asynchronous request message from the outbound message bus 62b. 

The encoded asynchronous sen/ice request message is then sent to service 
provider system 16. 

The service provider system 16 then processes the asynchronous service request 
25 message to generate a sen/ice response. Service response is then sent by the 
service provider system 16 to adaptor 40b. Service response includes the second 
correlation key. 
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The adaptor 40b then publishes the service response to inbound message bus 
6 J along with message context infomnation. The message context infom,ation 
indicates any enors that occurred during delivery and/or transfomiation. The 
published fom, of the sen,ice response includes the second correlation key. 

5 On publication of the seMce response, inbound message bus 62a notifies 
message receiver 64 of the existence of the seivlce response. The message 
mceiver 64 then retrieves the se^ice ^sponse ftom the Inbound message bus 
62a and decodes the message using the relationship associated with adaptor 

10 On analysis of «.e decoded service response, the message r^iver 64 confimrs 
the message to be a.servlce response by virtue of the existence of the second 
correlation key The decoded service response is then published to response 
message bus 62d with its second correlation key. 

Process executor 70 is then Infomied of the publlcatton of the decoded service 
15 response by response message bus 62d and retrieves the decoded service 
response from the response message bus 62d. The decoded sen,ice response is 
then used in further processing of the process model 48 as may be required. 

Processing of the process model 48 then proceeds until 1, reaches the 
synchronous service request. 

20 Again, as the synchronous service request is to be Issued to service pmvMer 
system 16, it ta necessary for the process executor 70 to encode the synchmnous 
service request. Encoding is made in accordance with the relationship associated 
wrlh adaptor 40b, itself associated with service provider system 16. The encoded 
synchronous service request is then published to outbound message bus 62b 

Z5 along with message context infbnnatlon. 

At this stage, further processing of the process model 48 by the PAE 42 is then 
halted pending return of a sen,ice response by service pmvlder system 16. 
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On publication of the encoded synchronous semoe request message, outbound 
message bus 62b notifies adaptor 40b of the publication of the encoded 
synchranous request message. Adaptor 40b then retrieves the encoded 
synchronous request message from the outbound message bus 62b and its 
5 message context infomiation. 

The encoded synchronous sen,ice request message is . then sent to sen,ice 

provider system 16. 

The sen/lce provider system 16 then processes the synchronous service ,«quest 
message to generate a sen,ice response. Service msponse Is then sent by the 
10 service provider system 16 to adaptor 40b. 

The adaptor 40b then publishes the sen,lce response to Inbound message bus 
62a along with message context infomiation. The message context Infomiation 
.nd,cates any enx,re that occun^d during delivery as well as any other lnfon.,atlon 
the adaptor 40b may include. 

15 On publication of the sen,lce response, inbound message bus 62a notifies 
message receiver 64 of the existence of the service response. The message 
^n-er 64 then retrieves the sen,lce response frem the inbound message bus 
62a and decodes the message using the relationship associated with adaptor 
40b. 

20 T^e decoded service response message Is then treated by the message receiver 
64 as a response to its series request and publishes the decoded service 
response to response message bus 62d. This correlation is made possible by the 
blocking of further processing of the process model 48 as described above. 

Process executor 70 is then infomied of the publication of decoded service 
response by response message bus 62d and retrieves the decoded service 
response from the response message bus. The decoded sendee response is 
then used in further processing of the process model 48. 
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Mor any reason. K ,s no. possible to process a client request, the cllen. recues. 
may be pubLshed to nefy message bus 620. Retry reoeh,er 68 Is a subscriber to 
the retry message bus 62c. Operaton of the retry receiver 68 Is similar to 
message receW^ 66. However, retry receivers 68 subscrip«on to retry message 
bu 62C allows for client requests to .main published on «,e .try message bus 
62c for a set penod of time before being retrieved. 

irjL"' r?"' ""^"'^ '° - ^'-ct^nic 

good trom electronic inventory 44. 

When process model 48 reaches a request tor an elect^nlc good to be Issued 
^m ele*on.c inventory 44, 1. Issues a service request to the eteCn^nlc Inventory 
44. in this manner, .for the purposes of dealing with sendee requests the 
^ec,.n,c inventory 44 Is treated the same as a service provider system 16 even 
though It IS an Internal component of the host server 12. 

Electronic Inventory 44 lecelves a sen^ request ftom the PAE 42 (as initiated by 
Process model 48). On receipt of the service request, the elect.,nlc inventory 44 
checks the sendee request for a sendee ID. The electronic inventoiy 44 then 
^ecks for an electronic good having the same service ID. Upon identifying a 
c»n^pond,ng electmnic good having the same sen,ice ,D, the elelnfe 
inventon, 44 operates to issue the electronic good to transaction device 14. 

At this pom^ processing of both the fl^t and second examples confom, 
Accordingly, the description hereafter relates to both examples. 

Following execution of a process model 48, a client response message is 
gene^ted indicating the success or fallu. of «,e client request, as appiopriate. 
A^rdingly, process executor 70 subscribes to inbound message bus 62a in 
order to ensure that the service response Is actually received by the tiansaotlon 
device 14 that issued the senrice request. The subscription Is based on a third 
correlation key. • « mira 
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The processor executor 70 thereafter encodes the client response message in 
accoitlance with the relationship associated with adaptor 40a. The encoded client 
response is then published to outbound message bus 62b along with all message 
context information that was received in the client request message. Thus, the 
5 encoded client response Includes the first con-elation key as well as a new third 
correlation key. 

Adaptor 40a is also a subscriber to outbound message bus 62b. Adaptor 40a 
subscribes on the basis of the first correlation key. AccoixJIngly. on publication of 
the encoded client response message, outbound message bus 62b notifies 

1 0 adaptor 40a of the publicatldn of the encoded client response message. Adaptor 
40a then retrieves the encoded client response message from the outbound 
message bus 62b. Adaptor 40a then operates to determine the client request that 
the encoded client response corresponds with by means of the first correlation 
key. Thereafter, the encoded client response is sent as a message to the 

15 Intermediate router. 

The Intemiediate router then fonvards the client response message to the 
transaction device 14. If the client response message indicates that the client 
request was unsuccessful, the transaction device 14 sends a payment reversal 
request to the payment host via the intermediate router. 

20 In either case, the adaptor 40a operates to send a delivery confimiation message 
to the PAE 42. The delivery confirmation message includes the third correlation 
key. The delivery confirmation message confirms with the PAE 42 that the 
response has been delivered to the appropriate transaction device 14. 

The adaptor 40a then publishes the delivery confirmation message to inbound 
25 message bus 62a. 

On publication of the delivery confimiation message, inbound message bus 62a 
notifies process executor 70. Process executor 70 then retrieves the delivery 
confirmation message from the Inbound message bus 62a. 
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If no delivery confirmation message Is received within a predetermined time 
period, process executor 70 treats the delivery as a failure. On failure of a 
delivery, roll-back commands are processed to reverse the processing perfomied 
by the PAE 42 in executing the process model 48 to which the failed delivery 
5 relates. This may include sending roll-back commands to service provider 
systems 16. 

From the point of view of a transaction device 14. this Is shown graphically at 
Figure 4. 

It should be appreciated by the person skilled in the art that the invention is not 
10 limited to the examples described. In particular, the following additions and/or 
modifications can be made without departing from the scope of the Invention: 

• the user Interface generated by the transaction application may 
operate to receive Input by means of an integrated keypad of the 
transaction device 14. Alternatively, input may be provided by means 

15 of a touchscreen through which the user interface is also displayed. 

• Authorisation procedures can be implemented where multiple, 
unrelated merchants or operators use the same electronic, 
transaction system 10. In such an arrangement, transaction details 
may be filtered such that details only relevant to the merchant or 

20 operator are shown. 

• Front-end adaptors 40a may be modified to provide means for 
confimiing the identity of a transaction device 14 from which it 
receives a transaction message. If the Identity of a transaction 
device 14 can not be confirmed, the transaction message will be left 

25 to timeout on the assumption that the transaction message 

represents an attempted breach of security. Additionally, checks 
may be made against the capacity of a transaction device 14. In this 
manner, the host server 12 can seek to ignore transaction devices 14 
that may be extemally controlled as part of a denial of service attack. 
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• Adaptors 40 may be in pemianent communication with its associated 
transaction device 14 or associated service provider system 16, as 
appropriate. If communicating via TCP/IP this may be by means of a 
single socket. 

• The transaction device 14 may be adapted to include removable, 
writeable media, such as a memory stick, floppy disk, compact disc 
or digital video disc. In this manner, the transaction device 14 can 
record an electronic good, or document, on the writeable media 
which the customer can then take away with them. 

. Transaction device 14. via intemiediate router, may operate to obtain 
a pre-authorisation Indication from the payrtients host rather than 
actually transacting a payment. Accordingly, if the service response 
indicates that the service request was unsuccessful, a reversal 
payment request need not be made. However, if the service 
response indicates that the service request was successful, 
confirmation of payment can then be made by the payments host in 
response to a request issued by the transaction device 14. via the 
intermediate router.. 

In a further arrangement, transaction device 14 may omit the 
payment application. In such an arrangement, intermediate host may 
also be omitted, a modem or other communications device integrated 
Into the transaction device 14 operable to establish a direct 
connection with host server 12. Alternatively, transaction device 14 
may incorporate one or more applications in addition to the payment 
and transaction applications. In this anrangement, as illustrated in 
Figure 5. such applications may be managed by a multi-application 
manager module so as to properly control access to resources, such 
as the modem and screen, by each application. Thus, payment can 
be made by way of a standard payment application, or a non- 
standard payment application, such as a loyalty point payment 
application. 



10 



15 



20 



25 



WO 2005/001725 

PCT/AU2004/000855 

-34- 

• All transmissions to and from host server 12 may be encrypted 
Ideally, any encryption technique used meets the encn^ptlon 
standards set for financial Institutions. 

. While the transaction device 14 has been described as including a 
modem for communication with the intemiediate router/host sender 
12. It should be appreciated by the person skilled in the art that any 
communication means may be used. Yet further, the transaction 
device 14 may be In direct connection with the Intemiediate 
router/host sender 12. as apprapriate. In which case the 
communication means takes the form of communications software 
stored in the memory of the transaction device 14. 

• Process model 48 may be arranged such that steps 50 may resolve 
to a fail value and values other than Boolean values. 

• Message buses 62 may implement messaging mechanisms other 
than the publish/subscribe mechanism referred to herein For 
example, direct communication or '•blackboard"-like messaging 
arrangements may be used. 

. Electronic inventory 44 may be adapted to dispense electronic goods 
of a smgle type. In such an an^ngement. serial IDs may be omitted. 

• The transaction device 14 need not be a dedicated device with 
embedded software. The transaction device 14 may actually be a 
personal computer or an Integrated cash register. 

. Content need not be scheduled for download at specified times but 
may be downloaded on creation. In this manner, content can be 
provided to the transaction devices 14 on an almost "real-time" basis 
following its creation via the content management system 22 



